EANCOM EDI is een Ascii gebaseerd bericht. In EDI wordt elke regel afgesloten door een ' teken en bij voorkeur (in verband met leesbaarheid) met een CR/LF. De scheiding tussen 'segmenten' in een regel vindt plaats door middel van een + teken en de scheiding tussen velden in een segment op een regel door middel van het : teken. Bij sommige regels zijn meerdere + tekens direct achter elkaar te vinden, hier staan dan segmenten tussen die in de GS1 DHZ (Doe Het Zelf) standaard niet gebruikt worden. Het is dan wel van belang het correcte aantal + tekens aan te houden zoals uit onderstaand voorbeeld. Ook is het zeer belangrijk dat de :, + en ' tekens niet als data worden gebruikt! Ook de volgorde van velden is belangrijk, deze mogen niet afwijken van de specificaties. Zo komt een (overigens optioneel) PRI veld in een order bericht altijd ná de QTY regel en moet een IMD veld zich altijd tussen de LIN en de QTY regels bevinden.

Een voorbeeld EDI verkooporder is te vinden in de bijlage van deze documentatie. In onderstaand overzicht wordt elke regel van een EDI verkooporder bericht uitgelegd. Dit bericht voldoet niet geheel aan de GS1 EANCOM standaard, een aantal regels zijn hier verplicht gesteld vanwege de webshop koppeling. Bij normale EDI berichten kunnen een aantal hier als verplicht gemarkeerde regels toch achterwege gelaten worden.

Verplicht: Startregel bericht
UNA:+.? '
Verplicht: Bericht van webshop met aansluitnummer 9999999999999 naar RetailVista met aansluitnummer 9999999999999. Voor webshop orderberichten wordt altijd het vaste afzender en bestemming aansluitnumer 9999999999999 gebruikt.
UNB+UNOA:4+9999999999999:14+9999999999999:14+100615:1041+INTREF++++++'
Verplicht: Orderbericht
UNH+1+ORDERS:D:96A:UN:EAN008'
Verplicht: Gewone order met webshop ordernummer 1148 (alfanumeriek, 17 karakters max)
BGM+220+1148+9'
Verplicht: Order datum en tijd (JJJJMMDDHHMM), tijd in 24 uur notatie
DTM+137:201006151042:203'
Verplicht: Order afkomstig van webshop met aansluitnummer 9999999999999
NAD+BY+9999999999999::9'
Verplicht: Order bestemd voor RetailVista met aansluitnummer 9999999999999
NAD+SU+9999999999999::9'

Verplicht: Klantnummer en adresgegevens van webshop klant. Als deze gegevens bij een bestaande klant worden meegeleverd dan wijzigt RetailVista de bezoekadres gegevens. Velden hier zijn achtereenvolgens ‘Klantnummer (Int64)’, 'Adres aanduiding (bijvoorbeeld ter attentie van)' (35 karakters), 'Straat' (35 karakters),’Huisnummer’,’Huisnummer toevoeging’, 'Plaats' (35 karakters), 'Postcode' (9 karakters), 'Landcode' (2 karakters). Bij de straat moet een huisnummer meegestuurd worden, gescheiden van de straat door middel van een spatie. Het klantummer mag leeg gelaten worden als de webshop geen klantnummers ondersteund. Voorbeeld adres is Nieuwweg 14b met als toevoeging de tekst ‘Thv Woonboten’.
NAD+DP+13245::9++THV WOONBOTEN+NIEUWWEG+14+B+GROTESTAD++1234AZ+NL’

Optioneel: Aansluitnummer van afwijkend afleveradres. Als dit veld gebruikt wordt, dan moet het EDI aansluitnummer bekend zijn bij een relatie binnen RetailVista, anders zal het orderbericht afgekeurd worden. Als het aansluitnummer bekend is in RetailVista, dan is binnen RetailVista ook adres informatie bij aanwezig. Vaak wordt in dit veld het partynumber (EDI aansluitnummer) van de geselecteerde vestiging gebruikt waar een webshop bestelling afgeleverd moet worden.
NAD+DP2+8714319928819::9'

Optioneel: Afwijkend afleveradres van webshop klant. Als dit veld gebruikt wordt, dan zal bij de verkooporder een afwijkend afleveradres vastgelegd worden. Hoewel toegestaan is het niet verstandig om zowel NAD+DP2 als NAD+DP3 te gebruiken: als beide velden gebruikt worden, dan zal NAD+DP2 voorrang krijgen in de uiteindelijk order verwerking. Voorbeeld adres is Frederikhaven 23k met als toevoeging de tekst ‘TO Flat gallerij’.
NAD+DP3+::9++TO FLAT GALLERIJ+FREDERIKHAVEN+23+k+KLEINESTAD++4321ZA+NL’

Optioneel (verplicht bij nieuwe klant): Naam van klant (alfanumeriek, bedrijfsnaam, achternaam, voorvoegsel, voornaam, email. Bedrijfsnaam, achternaam en email 60 karakters max). Indien geen bedrijf dan MOET de bedrijfsnaam leeg blijven. Velden moeten gescheiden worden door middel van | symbool. Als een bedrijfsnaam gebruikt wordt, dan wordt de contactpersoon informatie uit deze regel als contactpersoon toegevoegd bij de relatie informatie. De verkooporder wordt dan ook gekoppeld aan deze contactpersoon.
Het Email adres uit deze regel wordt als email adres toegevoegd aan de gevonden relatie. Als de relatie een bedrijf betreft, dan wordt het email adres gekoppeld aan de contactpersoon bij dit bedrijf/relatie.
CTA+OC:Slijterij Janssen|Visser|de|Alex|alex@slijterijjansen.nl'

Optioneel: Telefoonnummer klant (alfanumeriek, 512 karakters max). Als dit gegeven bij een bestaande klant wordt meegeleverd dan voegt RetailVista dit telefoonnummer toe aan de klant als het telefoonnummer nog niet bekend is.
COM+0527249900:TE'

Optioneel: Geheel levering in plaats van deellevering, regel weg laten in geval van deellevering
ALI+++83E'
Optioneel: Indicatie spoedlevering, regel weg laten in geval van deellevering
TOD+3++02E'
Optioneel: Klant referentie JAN98444
RFF+CR:JAN98444'

Verplicht: Regel 1, artikelnummer 8719400639032
LIN+1++8775143268748:EN'
Verplicht: Aantal 1 stuk
QTY+21:1'
Verplicht: Prijs 6,99 euro per stuk
PRI+LBL:6.99'

Regel 2, artikelnummer 8719400643657
LIN+2++8711577001230:EN'
Verplicht: Aantal 5 stuks
QTY+21:5'
Verplicht: Prijs 4,75 euro per stuk
PRI+LBL:4.75'

Regel 3, artikelnummer 9999999999999, dit is indicatie 'betaald bedrag' in combinatie met aantal van 1 stuk
LIN+3++9999999999999:EN'

IMD+C+35+::ZZZ:Ideal|ID-125652323'
Verplicht: Aantal 1 stuks
QTY+21:1'
Verplicht: Betaald is 30,74 euro op deze gehele verkooporder
PRI+LBL:30.74'
Verplicht in geval van betaling sectie: Betaling is gedaan via code 'Ideal' (code afstemmen met klant) met betaalreferentie ID-125652323 (max 35 karakters)

Regel 4, artikelnummer 9999999999998, dit is indicatie 'transport' in combinatie met aantal van 1 stuk
LIN+4++9999999999998:EN'
Verplicht in geval van transport sectie: Als transport is gekozen voor code 'Rembours' (code afstemmen met klant) (max 10 karakters)
IMD+C+35+::ZZZ:Rembours'
Verplicht: Aantal 1 stuks
QTY+21:1'

Regel 5, artikelnummer 9999999999997, dit is indicatie 'classificatie' in combinatie met aantal van 1 stuk
LIN+5++9999999999997:EN'
Verplicht in geval van classificatie sectie: Als classificatie is gekozen voor code 'Vuurwerk' (code afstemmen met klant) (max 10 karakters)
IMD+C+35+::ZZZ:Vuurwerk'
Verplicht: Aantal 1 stuks
QTY+21:1'

Regel 6, artikelnummer 9999999999996, dit is indicatie 'kostenplaats' in combinatie met aantal van 1 stuk
LIN+6++9999999999996:EN'
Optioneel veld waarin de kostenplaats van een order vermeld kan worden.
(code afstemmen met klant) (max 10 karakters)
IMD+C+35+::ZZZ:8010'
Verplicht: Aantal 1 stuks
QTY+21:1'

Regel 7, artikelnummer 9999999999995, dit is indicatie 'vrije opmerking' in combinatie met aantal van 1 stuk
LIN+7++9999999999995:EN'
IMD+C+35+::ZZZ:Graag leveren voor week 41'
QTY+21:1'

Verplicht: Sluitindicatie sectie
UNS+S'
Verplicht: Aantal regels in bericht vanaf en inclusief UNH en tot en met UNT regel
UNT+26+1'
Verplicht: Sluitregel bericht
UNZ+1+INTREF'

De gegevens van de regels NAD+DP+++, CTA+OC en COM+ regels worden altijd als opmerking bij de verkooporder vermeld.
Voor webshop omgevingen waarbij de klantinformatie niet op basis van klantnummer blijvend gemaakt kan worden is er een mogelijkheid om alle verkooporders op een zelfde vaste klantnummer door te geven, bijvoorbeeld de klant 'webshop' met bijvoorbeeld klantnummer 1.

Overleg het vaste te gebruiken klantnummer in dat geval met de RetailVista gebruiker. Het is dan wel aan de winkelier om de order te versturen naar de adresgegevens zoals in de opmerking bij de verkooporder is vermeld. In de testomgeving kan klantnummer 1 gebruikt worden.

De artikelnummers zoals aangegeven bij de LIN regels kan zowel een barcode als een artikelnummer zijn. RetailVista zoekt bij verwerking eerst naar de barcode. Als die niet gevonden kan worden, dan wordt nog gezocht of deze als artikelnummer bestaat.
De betaalregel sectie met code 9999999999999 is optioneel en moet weggelaten worden als er niet betaald is, bijvoorbeeld als er gekozen is voor 'rembours', 'machtiging', 'afhalen' etcetera. Het gaat om de volgende regels die in dat geval weggelaten moeten worden:
LIN+3++9999999999999:EN'
IMD+C+35+::ZZZ:Ideal|ID-125652323'
QTY+21:1'
PRI+LBL:30.74'

Elke betaalsectie wordt door RetaillVista als werkelijke betaling beschouwd en zorgt er voor dat RetailVista geen 'aanvullende' betalingen meer zal verlangen. Orders kunnen bij foutief gebruik dus zonder betaling worden doorgeleverd aan de klant. Om deze reden is het heel belangrijk dat de webshop producent zorgvuldig omgaat met deze betaal sectie.
In situaties waarbij het totaal te betalen bedrag 0.00 is, moet de betaalsectie worden weggelaten. Betalingen van 0.00 euro worden afgekeurd door RetailVista.

De type transport sectie is optioneel en mag weggelaten worden. Door deze sectie echter te vullen kan RetailVista een type transport opslaan bij een verkooporder, zodat de winkel goed kan zien voor welk soort verzending de webshop klant gekozen heeft. Vooral voor de eventuele nog uit te voeren betaling kan het type transport erg belangrijk zijn, bijvoorbeeld een rembours verzending. Het gaat om de volgende regels die weggelaten mogen worden:
LIN+4++9999999999998:EN'
IMD+C+35+::ZZZ:Rembours'
QTY+21:1'

De classificatie van de verkooporder is ook optioneel en mag weggelaten worden. Door deze sectie echter te vullen kan RetailVista een classificatie opslaan bij een verkooporder, zodat de winkel verschillende soorten orders uit elkaar kan houden. Een voorbeeld is de splitsing tussen bijvoorbeeld vuurwerk orders en normale klantorders. Het gaat om de volgende regels die weggelaten mogen worden:
LIN+5++9999999999997:EN'
IMD+C+35+::ZZZ:Vuurwerk'
QTY+21:1'

De kostenplaats van de verkooporder is optioneel en mag weggelaten worden. Door deze sectie te vullen kan RetailVista een kostenplaats opslaan bij een verkooporder, zodat de winkel bij een verkooporder weet welke vestiging de omzet/marge afdracht van die verkooporder mag ontvangen. Dit wordt alleen gebruikt bij meerdere vestiging situaties waarbij de verkooporders niet direct bij de uiteindelijke vestiging afgeleverd worden, maar waar alle verkooporders bij 1 hoofdvestiging afgeleverd worden. In onderstaand voorbeeld is kostenplaats 8010 gebruikt.
LIN+6++9999999999996:EN'
IMD+C+35+::ZZZ:8010'
QTY+21:1'

De opmerking bij een verkooporder is optioneel en mag weggelaten worden. Door deze sectie echter te vullen kan RetailVista deze opmerking opslaan bij een verkooporder, zodat de winkel geinformeerd is over wat een klant als vrije tekst bij een bestelling opgegeven heeft. Het gaat om de volgende regels die weggelaten mogen worden:
LIN+7++9999999999995:EN'
IMD+C+35+::ZZZ:Graag leveren voor week 41'
QTY+21:1'

De transport eigenschappen worden gebruikt om bij een transportwijze aanvullende eigenschappen op te geven. Dit is een tekstveld wat geheel vrij is qua inhoud. De werkelijke invulling hangt af van de technische partij die het bericht uiteindelijk logistiek gaat verwerken. Een voorbeeld van een dergelijke partij is Post NL. In die implementatie verwacht Post NL naast de productcode een optionele lijst van 'Product Opties' bij een verzending. Product opties zijn bijvoorbeeld niet bezorgen bij buren en avondbezorging. De Post NL implementatie binnen RetailVista werkt met name/value pairs, bijvoorbeeld:
ProductOption=118, 006
ProductOption=110, 002
De betekenis van deze opties is terug te vinden in de CIF documentatie van Post NL. In het transport eigenschappen veld kunnen afzonderlijke regels worden opgegeven door ze te scheiden met een ; teken. Een voorbeeld daarvan is hieronder te vinden.
LIN+8++9999999999994:EN'
IMD+C+35+::ZZZ:ProductOption=118,006;ProductOption=110,002'
QTY+21:1'

Door transport eigenschappen te gebruiken zullen eventueel vooraf gedefinieerde transport eigenschappen bij de pakketdienst binnen RetailVista worden genegeerd. In geval van Post NL zal dat betekenen dat eventueel opgegeven 'ProductOption' regels in de configuratie niet meegestuurd worden als er transport eigenschappen in het orderbericht gebruikt zijn.
Hopelijk is duidelijk dat dit veld algemeen is: bij andere pakketdiensten zoals bijvoorbeeld DHL kan dit veld anders ingericht moet worden. Neem eventueel contact met de supportdesk van NedFox om meer informatie te krijgen over de implementatie van dit veld bij andere pakketdiensten.

De geplande leverdatum van een order bericht is optioneel en mag weggelaten worden. In de praktijk zal deze datum vaak pas later bij de verkooporder toegevoegd worden (als dat veld al gebruikt wordt). Het is echter mogelijk om toch vanuit de webshop een geplande leverdatum mee te geven. Het datum formaat is dan yyyyMMdd.
LIN+9++9999999999993:EN'
IMD+C+35+::ZZZ:20170815'
QTY+21:1'

Bovenstaand orderbericht kan aan de ShopServer worden aangeboden via de method AddOrder(). De OrderText moet als een Base64 gecodeerde UTF32 string worden aangeleverd. De AddOrder() method retourneert de primary key zoals het bericht in de ShopServer opgeslagen wordt. Het is niet beslist noodzakelijk om die key te bewaren. In de ShopServer website kan een RetailVista gebruiker alle orders van de webshop terug zien.
In de situatie dat er subvestigingen bestaan en dat een order bij een subvestiging geplaatst wordt, is het nodig om het authenticatie token voor die (sub)vestiging mee te sturen. Het authenticatie token bepaalt in feite over welke vestiging er gecommuniceerd wordt.

Email

Als alternatief voor het gebruik van webservices is het ook mogelijk om orderberichten via email te ontvangen. Een RetailVista gebruiker ontvangt bij de webshop op verzoek ook een publiek email adres waarop order berichten ontvangen kunnen worden. Dit email adres eindigt op de domeinnaam @shopserver.co.nl. Het EDI order bericht mag als body text gestuurd worden, of als tekstbestand als bijlage. In dat laatste geval moet de body tekst beslist volledig leeg zijn!

Het voordeel van het gebruik van een email adres is dat deze techniek bij webshop producten bekend is en dat webservice integraties dus vermeden kunnen worden. Het nadeel is dat de ontvangst niet gegarandeerd is en dat er geen primary key ontvangen kan worden van de aangemaakte order. Uiteraard is de kans dat een email bericht niet aan komt niet bijzonder groot, aangezien deze door NedFox wordt opgevangen in een kwalitatief hoogwaardige omgeving.